Subject: New proposal for handling of time stamps in the APPC MIB

From: "R.E. (Robert) Moore (254-4436)" <[email-masked]>
Date: Tue, 21 Nov 95 13:52:05 EST

Based on Keith's comments (included in Bill Kwan's long note), we have to
agree that there are still some holes with our textual conventions for
MIB-centric time stamping.  On the other hand, we think there are real
implementation problems with sysUpTime-centric time stamping, so we
shouldn't just specify it everywhere and ignore the problems.

As a possible way forward, we'd like to propose the following solution:

1.  Remove the MIB-centric textual conventions such as AppcTimeStamp.

2.  For objects related to ongoing activities, always use durations
    (i.e., TimeTicks).

3.  For objects related to historical data (i.e, log records), always use
    DateAndTime.

Applying this solution to the APPC MIB would result in the following
changes:

   -  The AppcTimeStamp textual convention is removed.
   -  appcCntrlOperStatTime becomes a duration (TimeTicks).
   -  appcCntrlOperRscvTime becomes a duration (TimeTicks).
   -  appcCntrlOperTraceTime becomes a duration (TimeTicks).
   -  No change to appcUpTime:  it remains a duration (TimeTicks).
   -  appcActSessActiveTime is removed.
   -  No change to appcActSessUpTime:  it remains a duration (TimeTicks).
   -  No change to appcSessStatCtrUpTime:  it remains a duration
      (TimeTicks).
   -  appcHistSessTime becomes a DateAndTime.
   -  appcActConvStartTime is renamed appcActConvUpTime, and it becomes a
      duration (TimeTicks).
   -  appcHistConvEndTime becomes a DateAndTime.

If this solution is acceptable to the WG and to the IETF for the APPC
MIB, then we in the SNANAU WG / MIBs SIG can go ahead and apply it to the
APPN and SNA NAU MIBs as well.  It will be up to the DLSw MIB WG to
decide whether to apply it to their MIB as well.

Bob Moore